(2020-06-23)

编译过程

C语言的编译过程一般认为分为4个步骤：预处理、编译、汇编和链接。

假设现在有一个add.c的源文件，里面包含一个myadd()的函数，如下：

首先我们将该add.c文件直接编译成目标对象文件add.o，以备后用。

当然，还要有一个该文件的文件头add.h

如果我们在下面的源代码main.c中调用add.c文件中的myadd()函数

下面我们来逐步进行编译，首先是预处理：

查看main.i文件可看到多了很多行代码，其中很多一部分是因为我们include 中的内容，而我们自己写的add.h也通过文本替换进行了预处理：

然后是编译，将预处理之后的main.i翻译成main.s的汇编语言：

得到的汇编语言如下（省略部分内容）：

然后是编译，将汇编语言翻译成机器码，生成main.o的目标对象。

此时的目标对象并不是一个可执行的对象，我们可以使用nm命令来查看二进制文件中的函数。

这儿的myadd和printf都是U，即表示未定义。所以这也是为什么要进行链接的原因。

我们尝试执行下面的代码，直接从源文件，编译成最后的可执行文件。

会出现错误提示，因为我们前面提到了，myadd是一个未定义的对象。但是为什么没有提示printf错误呢？printf也是一个未定义的对象啊！

其实，gcc编译器在编译的时候会在系统默认路径下寻找相应的目标对象，而printf是C语言标准库中的函数，所以不用我们指定目标对象，gcc便能够找到相应的函数。但是，myadd，是我们在当前路径下自定义的一个函数，gcc不会在当前路径下寻找对应的目标对象，所以我们上述的编译过程就出现了无法找到myadd的错误。

为了解决上述问题，我们在编译的时候需要指定myadd函数所在的目标对象，即add.o。如果你想看一下链接到的C语言标准库，可以使用-Wl,--trace参数：

这儿， printf链接到了/lib64/libc.so.6动态库中。而myadd链接到了/home/shared/haha/C_learn/add.o目标对象中。

这时，再执行编译后的程序，就完全没有问题了。

静态库和动态库

你可能还会留意到一个问题，为什么在上面链接过程中，一个是.o的目标对象，而另一个是.so.6的文件？这就涉及到C语言函数库库的两种形式。

函数库一般分为静态库和动态库两种。

静态库是指编译链接时，把库文件的代码全部加入到可执行文件中，因此生成的文件比较大，但在运行时也就不再需要库文件了。其后缀名一般为”.a”。

动态库与之相反，在编译链接时并没有把库文件的代码加入到可执行文件中，而是在程序执行时由运行时链接文件加载库，这样可以节省系统的开销。动态库一般后缀名为”.so”，如前面所述的libc.so.6就是动态库。gcc在编译时默认使用动态库。

制作静态库比较简单，使用ar命令直接生成就可以了。比如，我们把上面add.o的目标对象转换成一个静态库。

习惯上，静态库以.a为文件名结尾。

然后我们将此静态库链接到之前的main.c源代码中：

此时生成的可执行。如果将libadd.a的静态库删除，那么main_static仍然可以执行。

2. 动态库

动态库在链接的时候并没有将代码拷贝到最终生成的可执行程序中，而是在执行的时候才去加载。动态库的使用很广泛，但是制作一个动态库要比静态库麻烦一些。

不同的操作系统中，我们习惯上使用不同的后缀名，在Linux上，动态库通常是.so结尾，在OSX上，通常是.dylib结尾，而在Windows上，通常是.dll结尾。

其中，-shared即表示创建一个动态库，-fpic (position-independent code)将绝对地址转换成相对地址，这样不同的程序可以在不同的虚拟地址中加载该动态库。

我们将上述动态库libadd.so链接到我们的main.c的程序中，

或者可以通过制定动态库名和路径来链接，如下：

这儿-L用来指定动态库所在的路径，-l用来指定库名称，注意这个库名称是libadd.so去掉前缀lib和后缀.so之后的名称。上述两种方法编译后的可执行程序是完全一样的。

此时我们运行上述在动态库上建立的可执行程序，如下：

此时居然提示错误，说找不到libadd.so的动态库！

这就是动态库和静态库的区别，静态库编译完成之后，完全不依赖于静态库，即便删除了静态库，程序仍然可以正确执行，但是动态库不一样，编译好的程序的运行需要依赖于外部动态库的存在。程序在运行时会按照一定的顺序寻找所需要的动态库，比如RPATH，LD_LIBRARY_PATH, /etc/ld.so.conf, /lib/, /usr/lib/等，如果在这些路径中没有找到所需动态库，那么就出出现上述错误提示。

因为我们自定义的libadd.so动态库并不在上述路径中，所以我们必须给链接器指定其所在的路径。一种方法是，我们可以把libadd.so所在的路径添加到链接路径LD_LIBRARY_PATH中，然后再运行程序，就不会出现错误了。如下

另一种方法是在我们链接的时候，使用RPATH，即“runtime library path”，该路径会保存在最后生成的可执行程序中，在程序运行中，会按照该路径寻找相应的动态库。如下，使用-Wl,-rpath来指定该路径。

我们比较一下加入了RPATH的可执行程序main_dyn1和没有加入该路径的main_dyn两个程序的链接情况，如下：

可以看到加入RPATH的main_dyn1程序已经可以成功连接到libadd.so动态库上了，而另一个则仍然提示没有找到对应的动态库。

和静态库相比，整个程序的运行完全依赖于动态库，所以如果你把动态库删除，上述程序仍然会提示错误。

综上，动态库相比于静态库，主要的难点就是如何在程序执行过程中顺利找到外部所依赖的动态库。而动态库的优点是能都很大程度上减少程序的大小。比如我们可以比较一下上述静态库链接的可执行程序main_static和动态库链接的可执行程序main_dyn的大小。

静态库链接的程序比动态库链接的程序大了16B。当然，此处它们相差不是太大，主要是我们的库文件很简单，如果是一个很大很长的库文件，那么静态库链接的程序可能会比动态库的大很多。

此外，动态库还能够更有效的利用内存。如果对库文件进行修改，我们也不需要重新编译程序。

后记：很多生信软件在安装的过程中，会用到各种C语言库，即便软件本身不是C语言写的，在安装过程中涉及到很多底层依赖库。而一旦出现错误，提示信息往往令人摸不着头脑，本文比较基础地简述了编译和链接过程，对理解软件安装过程中出现错误信息会有所帮助。

参考资料：https://blog.csdn.net/keneyr/article/details/87277585?utm_medium=distribute.pc_relevant.none-task-blog-baidujs-2https://stackoverflow.com/questions/8482152/whats-the-difference-between-rpath-and-lhttps://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.htmlhttp://nickdesaulniers.github.io/blog/2016/11/20/static-and-dynamic-libraries/https://www.quora.com/What-are-the-pros-and-cons-of-static-and-dynamic-linking-in-c++